Comodo has an existing API for certificate issue. It is functional and
works but it isn't ideal because:

1) It isn't JSON and we have customers that demand JSON.

2) It is proprietary which means we have to support plug ins for a large
number of servers which is costly and reduces the utility to larger
installations.

3) It is rather crusty as features have been added gradually over the years
by a variety of authors in a variety of styles.

If we follow the path of only addressing the problems considered important
by one CA that has yet to issue a cert then the result is only going to
address the first two problems. We will end up with another PKIX situation
where the stack is ridiculously complicated BECAUSE of the attempts to
'keep it simple'.

Lowballing requirements results in redundancy and unnecessary complexity.


A better way to address the problem is to architect the system recognizing
that in some circumstances functions will be split across different actors
at subscriber site at the start rather than trying to retrofit this
capability as an afterthought.

It isn't just enterprise firewalls that present corner cases. Managing
credentials on a Web service in the cloud presents similar issues.


*Architectural Constraints:*

* Use the existing CSR format for proof of possession of the private key
for X.509v3 issue.
* Use JSON encoding for all new structures and protocol messages.
* Assume HTTP binding, do not rely on HTTPS for security properties.
* Use SRV and CAA records in DNS to enable automation.


*Actors:*

Subject: The party whose identity is validated
Issuer: The party that issues the certificate
Host: The machine on which the private key and certificate are installed

Recognizing that the Host is not the same as the Subject is important as
without that distinction it becomes impossible to talk about failures or
attacks in a meaningful way.

Note that as far as the protocol interactions are concerned, the Issuer
need not be a CA. A CA is a party that is subject to audit and insurance
and has actual custody of the signing key. It is not actually necessary for
the Subject to have a direct interaction with their CA.

In the ideal situation any party with more than a dozen certs is going to
channel cert requests through a local issuer which forwards them to a CA
(possibly through another intermediary).


*Processes:*

Validation: Determining that a purported subject meets a set of criteria
specified by a certificate policy and in particular has the right to use a
specified identity.

Key Generation: Generating a public/private key pair

Certificate Issue: Signing a Certificate


While each process must occur at least once for a certificate to be issued,
these are three separate processes.

In particular, Validation is an interaction with the certificate subject,
Certificate Issue is to the Host holding the corresponding private key. In
any deployment that has more than one host it is going to be desirable to
amortize a validation process across the multiple hosts.


Today Key Generation and Validation might occur once every three years and
Certificate Issue once a year. One of the reasons I am interested in
automating Cert Management is to change these parameters.

My ideal situation would be to perform Key Generation and Certificate Issue
every 24 hours with overlapping 72 hour validity intervals of which 24
hours is backdated. I certainly don't want to have to perform OV or EV
validation every 24 hours.

I am not averse to performing the DV component of validation every 24 hours
as well but the most appropriate response to single validation failure
after a long stream of successful validations is probably to notify the
system admin rather than force their site offline.


A somewhat more complicated question is how to deal with the problem of
multiple ports, multiple protocols and multiple applications on the same
host.

We should not limit the use of HTTP validation to certificates that will be
used with HTTP.


While the requirements appear complicated, it is actually fairly
straightforward to support them all if we recognize the distinction between
the Subject and the Host. Since there is a relationship between the subject
and the issuer that potentially persists across multiple certificate issue
transactions, this implies some form of account/credential. Since we are
doing PKI we can insist that the credential used to authenticate
transactions be a public key.

For a free cert provider with a zero touch model, the account identifier
might well be simply the public key or a fingerprint thereof. If the
account identifier is never seen by a user, it does not need to be
particularly human readable.


Thoughts? Comments?